Method and apparatuses for end-to-edge media protection in an IMS system

ABSTRACT

An IMS system includes an IMS initiator user entity. The system includes an IMS responder user entity that is called by the initiator user entity. The system includes a calling side S-CSCF in communication with the caller entity which receives an INVITE having a first protection offer and parameters for key establishment from the caller entity, removes the first protection offer from the INVITE and forwards the INVITE without the first protection offer. The system includes a receiving end S-CSCF in communication with the responder user entity and the calling side S-CSCF which receives the INVITE without the first protection offer and checks that the responder user entity supports the protection, inserts a second protection offer into the INVITE and forwards the INVITE to the responder user entity, wherein the responder user entity accepts the INVITE including the second protection offer and answers with an acknowledgment having a first protection accept. A method for supporting a call by a telecommunications node.

This application is a continuation U.S. patent application Ser. No.12/744,720 filed May 26, 2010, which is now U.S. Pat. No. 8,549,615,which is a national stage filing of International Published ApplicationPCT/IB2008/003288 filed 1 Dec. 2008, which claims priority to U.S.Patent Application No. 60/991,014 filed Nov. 29, 2007.

TECHNICAL FIELD

The present invention pertains to media protection control with respectto a session control invitation message. (As used herein, references tothe “present invention” or “invention” relate to exemplary embodimentsand not necessarily to every embodiment encompassed by the appendedclaims.) More specifically, the present invention pertains to selectingan appropriate media protection, e.g. end to edge media protection withrespect to an SIP INVITE message in an IMS system between a initiatoruser entity and a responder user entity.

BACKGROUND

This section is intended to introduce the reader to various aspects ofthe art that may be related to various aspects of the present invention.The following discussion is intended to provide information tofacilitate a better understanding of the present invention. Accordingly,it should be understood that statements in the following discussion areto be read in this light, and not as admissions of prior art.

Many network access technologies (GSM, WCDMA, WLAN, WiMAX) provide somebasic security for the “first hop”. However, not all of them can beconsidered sufficiently secure and some accesses do not provide anybuilt-in security, e.g. IEEE 802.3. In particular, in fixed line accessthere is usually no logical protection of user traffic and thusprotection relies solely on the difficulty to access the physical mediacarrying the traffic. Therefore in “Fixed-Mobile Convergence” (FMC)scenarios there is a need to be able to provide at least IMS controlledend-to-access edge (e2ae) security, i.e. security for the mediatransport across the access network. This is needed to be able toprovide uniform protection of traffic in different types of networks.MMTEL is one such application which needs to be secured to earn users'trust. SRTP (RFC3711) and MIKEY (RFC3830) are examples of protocols formedia security and key management that have been proposed to this end.Other applications or enablers like IM, PoC and Presence, such as theones specified by the Open Mobile Alliance (OMA), would also benefit byan e2ae security solution.

Another type of media protection that might be needed for certainapplications is end-to-end (e2e) protection, i.e. from terminal toterminal (or terminal to application server for server basedapplications). However, true e2e protection would make it impossible toprovide network support for e.g. transcoding. In the description belowthe terminal to access edge solution is the focus. E2e protection ofmedia, true or with plaintext available for network supported functionslike PoC. are described in the international publication WO 2009/070075A1.

IMS according to 3GPP standard, the session control/set-up signaling isprotected between the P-CSCF and the terminal, either with IPSec or withTLS. Thus, the real need for protection from the terminal to the accessedge is only for the media traffic.

One possible solution for terminal to access edge protection of media,built upon an existing protocol, would be to use an IPSec tunnel betweenthe terminal and a security gateway (SGW) at the edge of the trusted IMScore domain (or at some other secure location). Such a tunnel couldprotect all media traffic from the UE to the edge of the secure network.However, use of IPsec tunnels gives heavy message expansion and makestraffic policing difficult.

It would, of course, also be possible to use existing protocols likeSRTP for media protection and MIKEY (or SDES) for key management toprotect the media path between the UE and e.g. the SGSN or C-BGF.However, applying it as is has the following problems in that a terminalto access edge solution may:

-   -   interfere with possible end-to-end solutions, in case the user        may use such for certain scenarios.    -   Cause problems with security policies between the home network        and visited network in a roaming situation.    -   Have problems with key management and authentication of        users/networks.    -   Lack means for the UE to indicate to the network prior to        session establishment if it supports media security at all and        if that is the case, which type of media protection it supports.

The invention in U.S. patent US 2006/0288423 to Franck et al providesmedia protection of media flows between a network element such as an endpoint, for instance a mobile user terminal, and another network elementover an access network. Franck et al does not disclose pre-registrationof media security capabilities of a user terminal that may result inexcessive control plane signaling.

BRIEF SUMMARY OF THE INVENTION

The present invention pertains to a SIP/IP Core System, exemplified herewith the IMS system. The system comprises an IMS initiator user entity.The system comprises an IMS responder user entity that is called (or ingeneral, invited to participate in media exchange) by the initiator userentity. The system comprises a initiator side S-CSCF in communicationwith the initiator entity which receives an INVITE having a firstprotection offer and parameters for key establishment from the initiatorentity, removes the first protection offer from the INVITE and forwardsthe INVITE without the first protection offer. The system comprises aresponder side S-CSCF in communication with the responder user entityand the initiator side S-CSCF which receives the INVITE without thefirst protection offer and checks that the responder user entitysupports media protection, inserts a second protection offer into theINVITE and forwards the INVITE to the responder user entity, wherein theresponder user entity accepts the INVITE including the second protectionoffer and answers with an acknowledgment having a first protectionaccept.

The present invention pertains to a method for supporting a protectedmedia session by a telecommunications node, such as an S-CSCF. Themethod comprises the steps of receiving a session control invitationmessage from a initiator user entity to a responder user entity havingan offer for media protection. There is the step of acting on the offerfrom the invitation message according to network policy. There is thestep of forwarding the message with a modified offer to the responderparty. There is the step of receiving an acknowledgment back from theresponder user entity. There is the step of modifying the acknowledgmentto include parameters to direct media traffic to an edge entity selectedto be a media protection end port and also information to establish acorresponding SA.

The present invention also pertains to a method for supporting aprotected media session by a telecommunications node, such as aresponder side S-CSCF. The method comprises the steps of receiving asession control invitation message from an initiator side S-CSCF userentity to a responder user entity having no offer for media protection.There is the step of acting on the offer from the invitation messageaccording registered security capabilities of the responder user entity.There is the step of forwarding the message with a modified offer to theresponder user entity. There is the step of receiving an acknowledgmentback from the responder party comprising a first protection accept.There is the step of removing the first protection accept in theacknowledgment, There is the step of forwarding the acknowledgementwithout the accept to the initiator side S-CSCF.

The present invention pertains to a media control signalling entityoperative in a communication network by processing and forwarding mediacontrol signalling messages between an initiator user entity and aresponder user entity. The media control signalling entity comprises afirst network interface for receiving a first invitation message fromthe initiator user entity, The media control signalling entity comprisesa second network interface for forwarding a second invitation message tothe responder user entity. The media control signalling entity comprisesa process unit in communication with said first and second networkinterfaces. The process unit operable for creating the second invitationmessage from first invitation message by:

determining if the first invitation message contains a first offer formedia protection

creating the second invitation message from the first invitation messageby:

at least removing the first media protection offer if included in thefirst invitation message,

at least inserting a second media protection offer if the firstinvitation message is without a first protection offer and if saidresponder user entity has registered at least one media securitycapability with said communication network, the second media protectionoffer corresponding said registered media security capability.

BRIEF DESCRIPTION OF THE DRAWINGS

In the accompanying drawings, the preferred embodiment of the inventionand preferred methods of practicing the invention are illustrated inwhich:

FIG. 1 is a simplified signaling diagram for controlling the use of e2aeprotection,

FIG. 2 is a diagram of an IMS network reference model.

FIG. 3 is a representation of the three different types of securityafforded by the present invention.

FIG. 4 shows another signaling diagram according to an embodiment of theinvention.

FIG. 5 is a block diagram of a media control signalling entity

DETAILED DESCRIPTION

Depending on the desired security level and the need to performoperations on the media in the network (e.g. transcoding) there is aneed to provide media security between the endpoints (user terminal) andan appropriate termination point in the network.

From security point of view, a “true” end-to-end solution, whereplaintext media and keys are only available at the endpoints (terminals)is clearly preferred. However, it makes network functions such astranscoding or lawful intercept difficult. The invention distinguishesthe following types of media protection.

End-to-Access-Edge (e2ae)

In this case, media is protected between the UE and some Edge Entity(EE). This solution solves the security problems related to any accesstechnology specific threats and since it decrypts the media “as early aspossible”, it enables transcoding/adaptation of the media anywhereinside the core and IMS networks.

End-to-Middle (e2m)

Here, traffic is protected between UE and some “middle-box”, e.g. theBorder Entity (BE) or some Application Server (AS) or enabler. It isassumed that outbound egress traffic from the AS/BE is re-encrypted asit exits. This provides for higher security (the only threat isbasically interception inside the BE/AS itself) but also means thatmedia manipulation is only (conveniently) possible in one place. Notethat the main difference between e2m and e2ae is that the entityterminating the security is slightly more “upstream” in the network andthat it is responsible for re-encypting outgoing traffic. Hence the maindifference lies in which node that is given access to the mediaprotection keys (the BE/AS or the EE) and we may therefore focus on thee2ae case, the e2m case being very similar. Thus, It should beunderstood that whenever e2ae procedures are discussed, e2m procedurescan be handled in analogy. When referring generically to a BE, EE, SGWor AS as termination point of e2ae or e2m security, the notation mediaplane handler is used.

End-to-End (e2e)

This provides the best security, but also causes the most problems forother media operations. Lawful Intercept will in this case be possibleas long as the keys are known in the network and can be performed eitherby delivering media together with keys to the Law Enforcement Agency(LEA), or delivering a decrypted media stream to the LEA. This is called“end-to-end with network support” (e2n2e).

Thus, there are reasons motivating support for all four scenarios: e2e,e2n2e, e2m, and e2ae. FIG. 3 shows the three options.

Referring now to the drawings wherein like reference numerals refer tosimilar or identical parts throughout the several views, and morespecifically to FIG. 1. thereof, there is shown an IMS system 10. Thesystem 10 comprises an IMS initiator user entity 12. The system 10comprises an IMS responder user entity 14 that is called by theinitiator user entity 12. The system 10 comprises an initiator sideS-CSCF 16 in communication with the initiator entity which receives anINVITE having a first protection offer and parameters for keyestablishment from the initiator entity, removes the first protectionoffer from the INVITE and forwards the INVITE without the firstprotection offer. The system 10 comprises a responder side S-CSCF 18 incommunication with the responder user entity 14 and the initiator sideS-CSCF 16 which receives the INVITE without the first protection offerand checks that the responder user entity 14 supports media protection,inserts as second protection offer into the INVITE and forwards theINVITE to the responder user entity 14, wherein the responder userentity 14 accepts the INVITE including the second protection offer andanswers with an acknowledgment having a first protection accept.

Preferably, the system 10 includes a user entity media plane handler 20,and wherein the responder user entity 14 derives key material andestablishes an SA together with a signal to the user entity media planehandler 20 instructing the user entity media plane handler 20 to enableimmediate protection based on the SA. The system 10 preferably includesa responder side P-CSCF 22 in communication with the responder userentity 14 which receives the acknowledgment from the responder userentity 14 and forwards the acknowledgment to the receiving end S-CSCF18. Preferably, the responder side S-CSCF 18 removes the firstprotection accept in the acknowledgment and forwards the acknowledgementwithout the accept to the initiator side S-CSCF 16. Establishing an SAcould comprise for instance the user entity and the media plane handlerperforming a key exchange or otherwise communicating the SA to the mediaplane handler.

The initiator side S-CSCF 16 preferably modifies the acknowledgment toinclude a second protection accept that the protection should be used.Preferably, the system 10 includes a initiator side P-CSCF 24 incommunication with the initiator side S-CSCF 16 and the initiator sideuser entity, and the initiator side S-CSCF 16 forwards theacknowledgment with the second protection accept to the initiator sideP-CSCF 24. The initiator side P-CSCF 24 preferably forwards theacknowledgment with the second protection accept to the initiator userentity 14.

Preferably, the initiator side user entity receives the acknowledgmentwith the second protection accept from the P-CSCF, derives key materialand establishes the SA together with a signal to the user entity mediaplane handler 20, instructing the media plane handler 20 to enable mediaprotection based on the SA. Establishing an SA could comprise forinstance the user entity and the media plane handler performing a keyexchange or otherwise communicating the SA to the media plane handler.

The present invention pertains to a method for supporting a protectedmedia session by a telecommunications node. The method comprises thesteps of receiving a session control invitation message from a userentity to a responder user entity having an offer for protection. Thereis the step of acting on the offer from the invitation message accordingto network policy. There is the step of forwarding the message with amodified offer to the responder party. There is the step of receiving anacknowledgment back from the responder party. There is the step ofmodifying the acknowledgment to include parameters to direct mediatraffic to a media plane handler selected to be a protection end portand also information to establish a corresponding SA.

Preferably, the receiving the session control invitation messageincludes the step of receiving an SIP INVITE message. The acting steppreferably includes the step of removing the offer from the INVITEmessage. Preferably, the network policy comprises information on thesuitability of end to end vs end to access edge protection, e.g. impliedby the need to perform transcoding, etc. Preferably, the receiving theINVITE message step includes the step of receiving the INVITE messagefrom an initiator IMS user entity to a responder IMS user entity havingthe offer for protection. The receiving the INVITE message steppreferably includes the step of receiving the INVITE message having theoffer which includes parameters for key establishment.

Preferably, there is the step of deriving keys for the protection to beused with the SA. There is preferably the step of the IMS initiatorand/or responder user entity registering media security capabilities ofa terminal. Preferably, the media security capabilities include at leastone of end to access edge, end to end with network support functionsallowed, or true end to end protection. The deriving step preferablyincludes the step of deriving the keys from already existing securityassociations used to protect SIP signaling, or with a key managementsystem, or from on-line key generation at the terminal based on publickey solutions.

Preferably, there is the step of instructing a P-CSCF to derive the keyand sending it to a media plane handler together with instructions thatmedia protection should be used. There are preferably the steps ofretrieving the SA from either a P-CSCF or an S-CSCF, deriving the keyand sending the key to a media plane handler together with instructionsthat media protection should be used. Preferably, there are the steps ofinstructing a media plane handler that media protection is applied andthe media plane handler requesting the key from a P-CSCF.

The present invention also pertains to a method for supporting aprotected media session by a telecommunications node, such as anresponder side S-CSCF. The method comprises the steps of receiving asession control invitation message from an initiator side S-CSCF userentity to a responder user entity having no offer for media protection.There is the step of acting on the offer from the invitation messageaccording registered security capabilities of the responder user entity.There is the step of forwarding the message with a modified offer to theresponder user entity. There is the step of receiving an acknowledgmentback from the responder party comprising a first protection accept.There is the step of removing the first protection accept in theacknowledgment. There is the step of forwarding the acknowledgementwithout the accept to the initiator side S-CSCF.

Referring to FIG. 5, the present invention pertains to a media controlsignalling entity operative in a communication network by processing andforwarding media control signalling messages between an initiator userentity and a responder user entity. The media control signalling entitycomprises a first network interface for receiving a first invitationmessage from the initiator user entity. The media control signallingentity comprises a second network interface for forwarding a secondinvitation message to the responder user entity. The media controlsignalling entity comprises a process unit in communication with saidfirst and second network interfaces. The process unit operable forcreating the second invitation message from first invitation message by:

determining if the first invitation message contains a first offer formedia protection

creating the second invitation message from the first invitation messageby:

at least removing the first media protection offer if included in thefirst invitation message,

at least inserting a second media protection offer if the firstinvitation message is without a first protection offer and if saidresponder user entity has registered at least one media securitycapability with said communication network, the second media protectionoffer corresponding said registered media security capability.

The second media protection offer can be an offer for end to access edgemedia protection. The first and second invitation messages can be SIPmessages. The media control signalling entity can further comprisesS-CSCF functions.

In the operation of the invention, the invention is described in an IMSframework. First, it is noted that an IMS user must REGISTER with theIMS system 10 and that when registering, the end user should alsoregister the media security capabilities of the terminal. The inventionintroduces three new media-security capabilities as discussed above, endto access edge (e2ae), end to end with network support functions allowed(e2n2e) or true end to end (e2e) protection. Note that these securitycapabilities need to be accompanied with indications of the type of keymanagement and security protocols that the terminal supports. In thisdescription, it is assumed that terminals at least register support fore2ae protection. For the key management there are three distinct usecases. The first is that keys are derived from already existing securityassociation used to protect the SIP signaling, the second case is when aseparate key management system is used, in particular key management asdescribed in the international publication WO 2009/070075 but also withpredistributed keys, and finally the third key management system is torely on on-line key generation in the terminals based on e.g.Diffie-Hellman (DH) or other Public Key (PK) solutions, e.g. accordingto MIKEY or IKEv2. The security protocol is preferably SRTP, but alsoother protocols such as TIS, IPsec, etc., are possible.

For e2ae media protection, it is allowed that the initiator andresponder user entity in principle are treated independently. Forinstance, the initiator may get one type of media protection and theresponder may get another type (possibly no protection). In thedescription below, the initiator side procedures is first described andthen the responder side procedures.

A user in IMS, initiating a call, sends an INVITE message to theresponder party. The INVITE message may include an offer for e2aeprotection. This offer is detected and handled by the initiator sideS-CSCF, which will remove it from the INVITE before the INVITE isforwarded to the responder party. When the responder party returns a“200 OK”, the S-CSCF will modify the OK to indicate that the protectionoffer has been accepted, The modified OK message will include allparameters needed by the terminal to direct its media traffic to theedge entity selected to be the protection endpoint and also allinformation needed to establish the corresponding SA. As alreadymentioned, the key(s) to be used can be derived from already existingSA's shared by the terminal and the network, established with the helpof a separate key management system 10 or they could be generated on thefly (D-H, PK) by the protection end-points. An example of a protectionmechanism based on key generation in the endpoints is the solutiondeveloped in IETF, which is called RTPSEC.

Now, with reference to FIG. 4, if the initiator terminal excludes thee2ae protection offer but the initiator side S-CSCF still wants toenforce use of e2ae protection, it may act on it by sending a SIP errormessage (e.g. “488 NOT ACCEPABLE HERE”) message indicating that theservice in the INVITE, i.e. no protection, is not available and indicateto terminal that it should use end-to-edge protection, e.g. due tonetwork (security) policy. Before doing this, it should of course checkthat the initiator terminal has registered that it supports this e2aecapability. The application of access edge to end protection at theresponder side could be a decision purely based on network policies.However, it could be envisioned that if the initiator side applies thistype of protection this is indicated in the SIP signaling to inform theresponder side that the call preferably should be given the same levelof protection at the responder side.

At the responder side the responder party's S-CSCF checks if theresponder terminal supports e2ae encryption, If so, it acts on it andinserts an offer for e2ae media protection in the INVITE message, Theterminal accepts the protection offer. The key generation/managementworks the same way as for the initiator side.

An offer to use e2ae protection can be carried e.g. in the SDP part ofthe SIP messages in accordance with e.g. MIKEY [RFC 3830, RFC 4567] orSDES [RFC 4568]. The keying information provided in the SDP part of themessage can later be used to setup SRTP. For other media, such as MSRP,PSK-TLS could be used, based on the keying information provided. Othermedia protection protocols may also be used to protect content/messagescarried in SIP by MESSAGE.

The key to be used for the media protection may be derived from the keysused to protect the SIP signaling between the initiator/responderterminal and the initiator/responder side P-CSCE. The key could bepushed to the media plane handler (e.g. SGW, AS, BE or EE) from theP-CSCF when P-CSCF from inspection of the SIP messages determines thatprotection should be applied or the initiator (or responder) side S-CSCFcan order the initiator (or responder) side P-CSCF to deliver them orthe S-CSCF can itself transfer the keying information. If the keyingmaterial comes from another SA the key distribution mechanism has to beadapted accordingly.

When a key management solution as described in PCT/SE2007/050927 isused, the calling terminal requests a key and a voucher from the KeyManagement Server (KMS) and includes the voucher in the INVITE. TheS-CSCE retrieves the voucher and presents it to the KMS which returnsthe key to be used. At the responder side the S-CSCF will request a keyand a (new) voucher from the KMS and include it in the INVITE. Theresponder will then present it to the KMS and request the correspondingkey.

E2n2e and e2m

The e2n2e and e2m case can easily be envisioned as slight variations ofthe above description.

The main difference for this case is that the controlling entity (e.g.S-CSCF/MRFC) has to make sure that not only the incoming media isprotected but also the ou going. If protection ends and begins in thesame node (typically for e2n2e) this should not be a real problem but ifthe protection ends in one node and begins in another node (e2m), somekind of indication needs to be signaled from the first node to thesecond node.

The (true) e2e case differs in that no network entities have an activerole in the signaling of the protection capabilities. In this case, thecalling/called party's S-CSCF would simply let the offer for protectionin the invitation pass through it (assuming the network policy allowse2e protection).

A very high level simplified signalling diagram can be found in FIG. 1.The description of the signalling flow is given below. It covers e2aeprotection when keys are based on existing SA's used to protect SIPsignalling.

1a/b The initiator UE registers with the IMS system 10 by sending aREGISTER including its capabilities regarding at least e2ae protection.

2a/b The initiator UE is authenticated to make the registration valid.

3a/b The initiator UE gets a 200 OK confirming the registration, and mayacknowledge support of the registered e2ae capability.

4 The initiator UE sends an INVITE containing an offer to use e2aeprotection including parameters for key establishment.

The initiator side S-CSCF 16 inspects the INVITE and notices that e2aeprotection is offered. As the network is capable of e2ae protection ittacitly accepts the offer and stores the decision.

Note that the initiator side P-CSCF does not do anything in this stage.

The initiator side S-CSCF may already now initiate SA derivation if itis done in the S-CSCF, and send the derived keys to the MRFC. If the keyderivation is done in the initiator side P-CSCF the derivation isdeferred,

5 The initiator side S-CSCF 16 removes the e2ae protection offer fromthe INVITE and forwards it to the responder side S-CSCF 18.

The responder side S-CSCF 18 inspects the INVITE and checks if theresponder party supports e2ae protection (it is assumed that theresponder has already registered this).

6 The responder side S-CSCF 18 inserts an e2ae protection offer beforethe INVITE is forwarded to the responder UE. The offer includesparameters necessary to establish a shared SA. The SOP part must also bechanged to route the media via the media plane handler (here assumed tobe a SGW) if the media plane handler is a separate entity, not includedin the normal media path.

The responder UE accepts the INVITE including the e2ae offer. It derivesthe keys to be used and establishes an SA together with a signal to theUE media plane handler 20 instructing it to enable media protectionbased on the that SA.

7 The responder UE answers with a 200 OK accepting the e2ae offer. Whenthe responder side P-CSCF 22 receives the 200 OK and if it is theresponsibility of the P-CSCF to generate SAs for e2ae protection itinspects the 200 OK derives the SA. The responder side P-CSCF would thenpush the SA and other information needed to the SGW and request that itenables media protection.

8 The responder side P-CSCF forwards the 200 OK to the responder sideS-CSCF 18.

If it is the responsibility of the responder side S-CSCF to generate theSA it would do that and push the information to the SGW (same procedureas described for P-CSCF).

9 The rec responder side S-CSCF 18 removes the e2ae protection accept inthe 200 OK and forwards the modified 200 OK to the initiator side S-CSCF16.

The initiator side S-CSCF 16 remembers that e2ae protection should beused and modifies the 200 OK to show this.

If it is the responsibility of the initiator side S-CSCF to generate theSA to be used, it does this and pushes it together with otherinformation needed by the SGW and requests the SGW to enable mediaprotection.

10 The initiator side S-CSCF forwards the 200 OK with the acceptance ofusing e2ae protection to the initiator side P-CSCF.

If it is the responsibility of the initiator side P-CSCF to generate SAsfor e2ae protection it inspects the 200 OK and notices that e2aeprotection has been agreed and thus derives the SA. The initiator sideP-CSCF would then push the SA and other information needed by the SGWand request that the SGW enable media protection.

11 The initiator side P-CSCF forward the 200 OK to the initiator UE. TheUE notices that the e2ae protection offer has been accepted and derivesthe keys to be used. It establishes an SA together with a signal to theUE media plane handler 20, instructing the media plane handler 20 toenable media protection based on the provided SA.

As stated above, the offers and answers could be carried in SOP usingSDES or MIKEY but other encodings can be envisioned.

In practice, the media security may be terminated in different edgedevices (media plane handlers) for IMS. It also depends on whether themedia plane handler is normally included in the media path, or, if thepresence of the media plane handler is only due to the need to act asend-point for e.g. e2ae protection. In the former case, signalling ofsecurity data to the media plane handler can be “piggy-packed” inalready existing set-up signalling, whereas in the second case, explicitsignalling (including a signal to the UE to re-direct its traffic) maybe needed. Above description differs slightly depending on place wherethe media will be terminated. If the protection ends in the MRFP, theMRFC will be the entity that needs to receive the derived keys from theS-CSCF and push this down to the MRFP.

The usage of the media security capabilities are as follows:

-   -   The terminal registers the supported capabilities. This is to        allow network initiated protection and this would most likely        only be e2ae or e2n2e.    -   The network may e.g. according to policy decide that certain        media-security modes are not supported and therefore indicate to        the UE that the media-security mode is not supported.    -   If more than one capability has been registered, this can later        be used either by the network, or another terminal to find out        what the best media security solution to use is, i.e. whether to        use e2e, e2n2e or e2ae.    -   In case a UE sends an INVITE to another UE with both, e.g., e2e        and e2ae offers, the entities in-between the two end points        needs to verify that they support these and/or that network        policy allows them. If e.g., one of these are not supported, the        network could indicate this e.g. by removing the capability it        does not support, so when the terminating UE receives the        request, it will have the choices left that both the originating        UE and all network entities in-between supports. Another way to        handle this is to let any network entity who does not support a        specific media-security capability to send back an error        indicating this. And the UE would then have to retry without        using that capability.

Keys for e2ae Protection Based on Existing SA's

If IPsec is used to protect the SIP signaling between the P-CSCF and theterminal, the used keys will be available in the P-CSCF and possibly inthe S-CSCF. If TLS based on server certificates and clientauthentication by http digest is used then the TLS SA will only beavailable in the P-CSCF.

Anyhow, the S-CSCF or an associated MRF will be responsible forperforming the policy control and initiating key derivation anddistribution. Depending on implementation choices made in existingsystems there are different options for how this function is bestimplemented. From a principal point of view the following options arepossible:

1. The S-CSCF/MRF will instruct the P-CSCF to derive the mediaprotection key and send it to the media plane handler together withinstructions that media protection should be used.

2. The S-CSCF/MRF will retrieve the SA from the P-CSCF (or S-CSCF),derive the key and send it to the media plane handler together withinstructions that media protection should be used.

3. The S-CSCF/MRF will instruct the media plane handler that mediaprotection shall be applied and the media plane handler requests thederived key from the P-CSCF.

4. The S-CSCF/MRF will instruct the media plane handler that it shouldexplicitly establish an SA with the UE, e.g. based on derived keysaccording to either of 1-3 above, or, using Diffie-Hellman of public keytechniques.

Keys Based on Vouchers

In this case, the S-CSCF/MRF will send a received voucher to the KMS andrequest the corresponding key. It would then send the key to the SGWtogether with instructions that media protection should be used. This isdescribed in more detail in the international publication WO 2009/070075A1.

When initiating protection the S-CSCF/MRF will request a key and voucherfrom the KMS.

FIG. 2 shows reference architecture used herein.

User/media plane nodes are shown in box 11 and SIP control plane nodesare shown in box 15. The EE is (some) edge entity at the edge of thefixed core network. BE is some border entity at the border between thetwo networks. The AS is some IMS application server or OMA enabler, e.g.a PoC server or an instant Messaging server. (In the notation usedabove, AS, EE and BE are all media plane handlers.)

FIG. 2 assumes both A and B are ISIM enabled users, but since IMS isassumed to be common to many different access technologies, the requireduse of (hardtoken) UICC may be too restrictive, in particular sincenon-ISIM based mechanisms already exist for IMS authentication.

A straightforward solution is to also allow usage of soft-ISIM. However,even this may be a limitation since there are also deployments of otherforms of user credentials, e.g. public/private keys distributed inhardware or software.

Therefore, although support for ISIM is a foremost concern, the solutiontargeted will only assume that some form of cryptographic (secret keybases) user credential is in use and that this credential can be used toauthenticate the user and establish a common shared (base) session key.Solutions that fall in this category are: ISIM, PKI, IBe (identity basedcryptography), username/password, etc.

The following are examples of IMS services which can be supported by theinvention.

MMTEL

By this, it is meant conventional peer-to-peer (P2P) multimediatelephony or a conference call in a small group. In the group case, itis assumed a “conference bridge” is implemented as an HAS AS or OMAenabler. Set-up is signaled via normal SIP mechanisms and the media iscarried by RTP. In the group case, the SIP servers (eSeF's) could forinstance modify the security in the SIP offers so that security is e2mprovided between each user and the AS or enabler.

Push-to-Talk

Here, Poe service refers to a service set up using SIP signaling andwhere a Poe server is used as application server (AS) or enabler todistribute RTP-transported media to the receivers. The “Poe server” inthe actual product usually refers to the control plane part, but here,it refers generically to both the control plane and media plane (MRF)parts as “the Poe server”. This case could be handled similarly to theconference call discussed above.

Messaging

This can either be messages carried directly in the SIP body, or, set upby SIP and carried over MSRP. An AS/enabler acts as messaging server.Also here the messages can be P2P or directed to a group.

Instant vs Deferred Services

Messaging services are typically implemented so that if the recipient isnot online, the message is automatically converted to a deferred messageand stored in an AS until the recipient registers. In fact, also MMTELand PoC can support deferred delivery with the server acting as a “phoneanswering machine”.

Besides well-known IMS related terms such as HSS, CSCF, MRF, etc., weuse the following abbreviations are used herein.

AS (IMS) Application Server

BE Border Entity

BSF Bootstrapping Server Function

EE Edge Entity

EPS Evolved Packet System

GSA Generic Bootstrapping Architecture

LEA Law Enforcement Agency

LI Lawful Intercept

NAF Network Application Function

NSPS National Security and Public

Safety P2P Peer-to-peer

CBGF Core Border Gateway Function

CSCF Call State Control Function

DH Diffie-Hellman

e2ae End-to-Access-Edge

e2e End-to-end

FMC Fixed-Mobile Convergence

GSM Global System for Mobile Communication

IKE Internet Key Exchange (RFC 4306)

IM instant Messaging

IMS IP Multimedia Subsystem (3GPP standard)

IPSec IP Security protocol (RFC 4301)

KMS Key Management SeNer

MIKEY Multimedia Internet KEYing (RFC 3830)

MMTEL MultiMedia TELephony

MRF Multimedia Resource Function

MRFC MRF Control

MRFP MRF Processor

MSRPMessage Session Relay Protocol (RFC 4975) P-CSCF

Proxy-CSCF

PK Public Key

Poe Push-to-talk over Cellular

PSK-TLS Pre-shared Key TLS

RTP Real time Transport Protocol (RFC 3550)

RTPSEC RTP Secure Keying

SA Security Association

S-CSCF Serving-CSCF

SDES Session Description Protocol Security Descriptions (RFC 4568)

SOP Session Description Protocol (RFC 4566)

SGW Security Gateway

SIP Session Initiation Protocol (RFC 3261)

SRTP Secure Real time Transport Protocol (RFC 3711)

TLS Transport Layer Security (RFC 5246)

UE User Equipment

WCDMA Wideband Code Division Multiple Access

WiMAX Worldwide Interoperability for Microwave Access (IEEE 802.16)

WLANWireless Local Access Network (IEEE 802.11)

Although the invention has been described in detail in the foregoingembodiments for the purpose of illustration, it is to be understood thatsuch detail is solely for that purpose and that variations can be madetherein by those skilled in the art without departing from the scope ofthe invention except as it may be described by the following claims.

The invention claimed is:
 1. A method for supporting a protected mediasession by a telecommunications node using control plane signalingcomprising: receiving a session control invitation message from aninitiator user entity and directed to a responder user entity, whereinthe session control invitation message includes a first offer ofprotection for a media session; modifying the offer of protection in thesession control invitation message; forwarding the modified sessioncontrol invitation message to the responder user entity; receiving,responsive to the modified session control invitation message, anacknowledgement from the responder user entity; modifying theacknowledgement from the responder user entity to indicate that thefirst offer of protection is accepted; and forwarding the modifiedacknowledgement to the initiator user entity.
 2. The method of claim 1,wherein modifying the offer of protection in the session controlinvitation message comprises removing the offer of protection.
 3. Themethod of claim 1, modifying the acknowledgement from the responder userentity further comprises including parameters for the initiator userentity to direct media traffic to a media plane handler selected to be aprotection end point.
 4. A media control signaling entity operative in acommunication network by processing and forwarding media controlsignaling messages between an initiator user entity and a responder userentity, said media control signaling entity comprising: a networkinterface for receiving a session control message; and a processing unitfor processing the session control message, said processing unitconfigured to: receive a session control invitation message from aninitiator user entity and directed to a responder user entity, whereinthe session control invitation message includes a first offer ofprotection for a media session; modify the offer of protection in thesession control invitation message; forward the modified session controlinvitation message to the responder user entity; receive, responsive tothe modified session control invitation message, an acknowledgement fromthe responder user entity; modify the acknowledgement from the responderuser entity to indicate that the first offer of protection is accepted;and forward the modified acknowledgement to the initiator user entity.5. The media control signaling entity of claim 4, wherein the processingunit is further configured to modify the offer of protection in thesession control invitation message by removing the offer of protection.6. The media control signaling entity of claim 4, wherein the processingunit is further configured to modify the acknowledgement from theresponder user entity further by including parameters for the initiatoruser entity to direct media traffic to a media plane handler selected tobe a protection end point.
 7. A method for supporting a protected mediasession by a telecommunications node using control plane signalingcomprising: receiving a session control invitation message having nooffer of protection from an initiator user entity and directed to aresponder user entity; modifying the session control invitation messagebased on registered media security capabilities of the responder userentity to include an offer of protection; forwarding the modifiedsession control invitation message to the responder user entity;receiving, responsive to the modified session control invitationmessage, an acknowledgement from the responder user entity, saidacknowledgement including a protection accept; modifying theacknowledgement from the responder user entity; and forwarding themodified acknowledgement to the initiator user entity.
 8. The method ofclaim 7, wherein modifying the acknowledgement from the responder userentity comprises removing the protection accept.
 9. A media controlsignaling entity operative in a communication network by processing andforwarding media control signaling messages between an initiator userentity and a responder user entity, said media control signaling entitycomprising: a network interface for receiving a session control message;and a processing unit for processing the session control message, saidprocessing unit configured to: receive a session control invitationmessage having no offer of protection from an initiator user entity anddirected to a responder user entity; modify the session controlinvitation message based on registered media security capabilities ofthe responder user entity to include an offer of protection; forward themodified session control invitation message to the responder userentity; receive, responsive to the modified session control invitationmessage, an acknowledgement from the responder user entity, saidacknowledgement including a protection accept; modify theacknowledgement from the responder user entity; and forward the modifiedacknowledgement to the initiator user entity.
 10. The media controlsignaling entity of claim 9, wherein the processing unit is furtherconfigured to modify the acknowledgement from the responder user entityby removing the protection accept.